Task execution is a well known operation in the art of computer programming. Tasks in modern operating systems such as UNIX.RTM. are executed within processes. In general, a process comprises a set of resources such as program code, variables, open files, sockets, and one or more threads (i.e, threads of control). A thread is an object created inside a process to keep track of a task's progress and status during execution.
Prior to executing a task, a client process generally receives task instructions via user input (e.g., a keyboard or disk), a computer program, or some other source. The client process then instructs one or more server processes to execute a task or tasks. In executing a task, processes must communicate with each other to 1) specify the task to be run and what data to use, and 2) receive results. Processes typically communicate with each other using sockets, which are communication objects with an address. Communication between sockets takes place over communication channels which are opened and closed as needed.
As used herein, the term "client process" refers to a process which requests execution of a task, and the term "server process" refers to a process which executes a task. Although client and server processes will typically exist on different computers, it is possible that client and server processes be launched within a single computer.
Computer systems are rapidly moving toward management of large numbers of computers from a single station. To do this, the managing station must be able to perform large numbers of identical tasks on thousands of remote computers. However, computers often lack enough resources to manage all of the computers executing tasks on their behalf. A typical solution is to execute a subset of the total number of tasks to be executed, and then execute the remaining tasks when any currently executing tasks have finished. Unfortunately, this solution results in undesirable delay.
Other situations wherein a computer initiates remote execution of a task also arise. For example, a computer with limited resources might request that a task be executed on a central computer with more extensive resources. Likewise, cases arise wherein a computer with limited resources needs to distribute task execution over several computers so that a large task can be completed more expeditiously.
When a user initiates a task in a network, a client process contacts a server process running on a remote server to execute the task. The client process and server process communicate with each other using communication managers, comprising a socket and associated program code to react to data as it is received. Thus, for a client process to execute tasks in a server process, the client process registers the task with its communication manager so that it will be expecting to receive the results of the task from the server process. The client process then opens a communication channel to the server process and instructs server process to execute the task. The server process creates a thread and executes the task in it, then reports results to the client process.
In the past, tasks have been executed either asynchronously, or most commonly, synchronously. Each form of task execution has its advantages and disadvantages. Synchronous tasks can tie up system resources more than asynchronous tasks if the task is a long one, but asynchronous tasks take longer to set up and execute.
To execute a task synchronously, the client process opens a communication channel to the server process and instructs it to execute the task as described above, waits while the task is being executed, then receives the results that the server process transmits. This has the disadvantage of tying up system resources while the task is executing. The communication channel remains open and may not be used for other tasks, sitting idle while a single task executes. When the task is complete the results are transmitted to the client process.
To execute a task asynchronously, the client process registers the task, opens a communication channel to the server process, sends the task request, then closes the communication channel. When the task completes in the server process, the server process reopens a communication channel to the client process and transmits the results.
Synchronous tasks require communication channels to remain open, but avoid the extra work of opening and closing communication channels when needed. Asynchronous tasks do not require communication channels to remain open, but require the extra work of opening and closing communication channels. Therefore, long tasks should be executed asynchronously to conserve system resources and to allow an increased number of tasks to be executed simultaneously, and short tasks should be executed synchronously to avoid the delay of setting up an asynchronous execution. However, determining which mode of task execution to use has been a difficult problem to solve.
Nonetheless, selecting the best execution method is becoming increasingly important as computer systems evolve toward management of very large numbers of computers by a single station, and the number of computers connected to networks increases. For example, executing even a simple task on hundreds of remote systems can take hundreds of times as long as the task itself if the managing station can only execute the task on a few remote computers at one time. Similarly, if all tasks are executed asynchronously to increase the number of remote computers managed simultaneously, the delay in opening and closing communication channels repeatedly for the hundreds of brief tasks involved in computer management becomes a large burden. Selecting synchronous or asynchronous task execution properly becomes increasingly more important as the number of remote systems increases.
Unfortunately, it is very difficult to determine how long most tasks will last, making it difficult to create a system which executes tasks differently based on premeasured execution durations. For example, a task may last a long time in one instance and a short time in others if execution time depends on the amount or the nature of the data it processes, or if it performs a first-use initialization. Task duration is also dependent on speed of the computer system and efficiency of the operating system. System loading also slows down task execution during busy periods. Furthermore, even if task duration was consistent, measuring and keeping track of task duration during development and programming of tasks would be difficult and tedious at best, and would have to be updated when the computer hardware or operating system changed.
Another burden on system resources imposed by task execution is the reporting of results. As soon as the task is completed in the server process, the results are transmitted back to the client process. This unmanaged use of system resources leaves the client process waiting idly at times, and overburdened at others.
It would be desirable to provide a method and apparatus for executing tasks in remote processes synchronously or asynchronously based on task duration without any prior knowledge about the task and to return the results without flooding the requesting process during busy periods. The present invention achieves all of these goals.